Communication networks can be composed of many network elements, such as switches, routers, media gateways, and multiplexers. These network elements may be monitored and managed by one or more management systems. Management systems may perform a variety of management functions including those related to fault detection, performance monitoring, accounting, configuration, and security (FCAPS). Typically, management systems are hierarchical for allowing network administrators to efficiently administer and troubleshoot a given area or subsystem of the network. For example, management data from a given type or system of NEs (e.g., a hybrid fiber/coax (HFC) cable-telephony system or digital cross-connect system) may be processed and analyzed at a given element management system (EMS).
FIG. 1 illustrates one example of a conventional hierarchical management system. In one embodiment, one or more element management systems may command, control, and monitor one or more network elements. In the embodiment illustrated in FIG. 1, communications network 100 includes EMS 102A, EMS 102B, and EMS 102C, collectively referred to as EMSes 102. Each EMS may control one or more network elements, collectively referred to as NEs 104. An EMS may interact with network administrators or third party applications, including higher level management systems, such as a network management system (NMS) or a operations support system (OSS), that analyze or control the interworking of multiple EMSs. In the embodiment illustrated in FIG. 1, EMSes 102 communicate with NMS/OSS 106, which may use EMSes 102 as an intermediary for controlling and managing NEs 104. It is therefore important that each EMS 102 communicates effectively with NEs 104.
Effective communication may involve an EMS being intimately aware of a managed NE's domain knowledge. As used herein, the term “domain knowledge” refers to information about the environment in which a system or network element operates, including information about the resources available within a network element itself. For example, the domain knowledge of a media gateway may include information about its protection groups, port numbers, and interfaces. NE domain knowledge is created or defined during NE development (e.g., by the software or hardware developers of the NE).
Typically, NE development is separate from EMS development. This may be the case even when both products are produced by the same company. As such, there is a typically a lack of communication and support between an EMS development team and NE development team. Accordingly, domain knowledge of an NE may not be provided or obtained in an effective or efficient manner. Instead, NE domain knowledge is usually gathered independently by the EMS development team. For example, an EMS development team may create and perform a variety of tests for communication and integration of an element and management system. Using these tests, the EMS development team may discover and fix bugs or issues, such as an incompatibility in validation logic. However, such tests may be cumbersome, expensive, and inefficient. For example, an EMS development team may develop inadequate integration tests and/or may receive information about an NE too late in the development process for adequate testing.
Accordingly, a need exists for methods, systems, and computer readable media for a validation framework for validating commands for configuring entities in a telecommunications network.